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PLANNER Proposal 



Task Objectives 

The task objective is the general tzat ion and 
Implementation of the full power of the problem solving 
formalism PLANNER in the next two years. We will show how 
problem solving knowledge can be effectively Incorporated 
into the formalism. Several domains will be explored to 
demonstrate how PLANNER enhances problem solving. 



Current Status 

Sublanguages of the PLANNER formalism have been 
implemented at M.I.T. We would now like to have the full 
power of the formalism available to us. The restrictions of 
the sublanguages we have now are cramping many of the 
current applications and discouraging other new 
applications. The work Is currently being pursued on two 
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time-shared computers: a Honeywell 6^5 and a Dir.ltal 
Equipment Corporation PDP-1Q. Pursuing work on two systems 
Instead of one Is somewhat unusual an 50 we will give a 
detailed justification. PLANNER should be Independent of 
any particular computer scries or time-sharing monitor. By 
Implementing on two systems we Insure that this Is true In 
practice as well as theory. HULTICS and ITS are currently 
the best systems available for PLANNER. Both systems are 
currently being upgraded so they will probably still be the 
best systems In a few years, M.I.T. has signed the contract 
for the follow on processor for MULTlCS. The Stanford A. I. 
Laboratory Is constructing a proto-type for the follow on 
processor for the PDP-10, Both follow on systems propose to 
have large amounts of fast random access memory and even 
larger virtual address spaces. If either one comes to 
fruition, then PLANNER can be applied to problems with large 
data bases. PLANNER uses hash coding so that the time that 
It takes to retrieve a fact Is essentially independent of 
the size of the data base PROVIDING there Is enough fast 
random access memory. One danger to be avoided In this 
approach Is duplicating work on the two systems. So far the 
Interaction between the two implementations has been 
extremely f rui tful . 

The following is a detailed comparison of MULTlCS 
and ITS for the purpose of Implementing PLANNER: 
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Fast Random Access Memory: MULTICS has fcOOK and ITS 
has 250K. For acceptable response It should be the 
case that the working sets of all the users fit Into 
fast random access at once. In the day shift both 
systems often respond slowly. They need either 
fewer users or more memory. 

Address Space: MUlTlCS has a 36 bit address space 
which Is adequate for our medium term needs. The 
mapping Is implemented by dividing the address space 
into segments in a way which Is sometimes annoying 
but usually not too harmful. ITS has an 18 bit 
address space which is entirely Inadequate for our 
needs. The follow on processor for the PDP-10 will 
have a larger address space. PLANNER uses the 
address space for dynamic linking, garbage 
col lection, and breathing space between data spaces 
(especial ly stacks). 

File System: ITS has an adequate file system, 
MULTICS has a good file system In which the files 
can be put In the address space of a process which 
makes It very easy to manipulate files. 

Speed; The processors for the two systems execute 
Instructions at approximately the same speed. 
Because of an administrative decision to keep ITS 
lightly loaded, It *ives much faster response. 

Consoles: ITS has consoles that run at a maximum 
rate of 2**00 Baud which Is somewhat slow, Multlcs 
Is currently experimenting with connecting an IMLAC 
with a 200,000 Baud line. Fast consoles are 
essential for the use of PLANNER, PLANNER Is a 
unified system In which editing, debugging, 
monitoring, metering, and executing all take place. 
It Is not necessary or deslreable to use a separate 
editor, compiler, or debugger. Slow consoles would 
be a real bottleneck in the system. 
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Next Year 

In the next year we would like to complete the 
design and implementation of extended PLANNER* The design 
villi support the complete formalism as described In Hewitt's 
thesis. Specifically extensions will be Incorporated to 
encompass multiple states of the world and multiple 
processes. Multiple states will enable PLANNER to easily 
and directly compare the situations that would result If 
alternative plans of action v/ere followed. Multiple 
processes will enable PLANNER to have more than one locus of 
problem solving activity In existence at one time* To prove 
out our Ideas we will develop several simple domains such 
as: 



A simple logistics and transportation system with 
5Uppl y depots. 

A robot like blocks world with more than one arm 50 
that It Is necessary for two processes to cooperate 
to accomplish some of the tasks, 

A negotiator for the game of Diplomacy which would 
have the knowledge needed to try to survive in a 
cooperative-competitive world. 
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A Simple Example 

We would like to give an example of how simple 
requests can be handled In PLANNER* Suppose manufacturer X 
has just gone bankrupt. Which of our products are affected? 
In order to get PLANNER to do anything, a goal oriented 
procedure must be written, because of the powerful 
procedure definition machinery in PLANNER arbitrary 
Inferential searches can be carried out. PLANNER Is not 
limited to being able to answer the fixed number of kinds of 
questions that the system builder happened to think of. The 
formalism Is designed to make It easy for PLANNER procedures 
to construct other PLANNER procedures. Terry WInograd has 
shown In his thesis how it is possible to translate English 
requests like "Find all products which are effected' 1 Into 
the PLANNER procedure! 

<f Ind al 1 .product 

<goal [affected-by : product. XI>> 

The above PLANNER statement says the problem Is to find all 

products which are affected by X, At this point the system 

will comment: "I don't know how to find out whether a 

product Is affected by a manufacturer". The user might 

reply: "A part Is affected by a manufacturer If the 

manufacturer makes It or If It has some subpart which Is 

affected by the manufacturer". Thus the following procedure 
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Mould be generated by the natural language translator: 

<consequent I I 

laffected-by ?part ?manufacturer | 
<or 

<goal | manufactures ?nianufacturer ?part |> 
<and 

<goaI |part-of ?subpart ?part|> 
<goal 

|af fected-by 
?subpart 
?manuf acturer I >>>> 

The above statements are In o form which can be directly 

executed by PLANNER. By these means PLANNER can solve 

problems that were unanticipated by the original system 

builders. PLANNER will execute the above request 

efficiently even on a large data base because It indexes its 

data base using hash coding. 
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Biographical Note 



Carl Hewitt was born In Clinton, Iowa, but considers 
himself a native of El Paso, Texas to which he moved at the 
age of two years* He attended El Paso Public Schools and 
graduated from El Paso High School In 1063. With a 
McDermott Scholarship, he attended MJ.T. In 1967 he 
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Comparative Schematology (with Michael Paterson). 
Proceedings of Project MAC Conference on Paralllsm. June 
1970. Woods Hole, Mass. 

PLANNER: A Language for Proving Theorems In Robots. 
Proceedings of IJCAI , May 7-9, 1969. Washington D. C. 

Teaching Procedures In Humans and Robots. 
Proceedings of Conference on Structural Learning. April 5, 
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197U, Philadelphia^ Pa. Journal of Structural Learning. 

Procedural Embedding of Knowledge In PLANNER. 
Proceeding of Second International Joint Conference on 
Artificial Intelligence. Sept. 1-h, 1971. London. 

Description and Theoretical Analysis (using 
Schemata) of PLANNER: A Language for Proving Theorems and 
Manipulating Models In a Robot. Phd thesis at M.I.T. Jan. 
1971. 



Appendix I* 
The Structural Foundations of Problem Solving 



The following was extracted from chapter 2 of 
Hewitt's thesis. It gives an overview of PLANNER. Detailed 
information Is available In the Ph, D. theses of Hewitt and 
Wlnograd. 

We would like to develop a foundation for problem 
solving analogous In some ways to the currently existing 
foundations for* mathematics. Thus we need to analyze the 
structure of foundations for mathematics. A foundation for 
mathematics must provide a definitional formalism In which 
mathematical objects can be defined and their existence 
proved. For example set theory as a foundation provides 
that objects must be built out of sets. Then there must be 
a deductive formalism In which fundamental truths can be 
stated and the means provided to deduce additional truths 
from those already established. Current mathematical 
foundations such as set theory seem quite natural and 
adequate for the vast body of classical mathematics* The 
objects and reasoning of most mathematical domains such as 
analysis and algebra can be easily founded on set theory. 
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The existence of certain astronomically large cardinals 
poses some problems for set theoretic foundnt ions. However , 
the problems posed seem to be of practical Importance only 
to certain category theorists* Foundations of mathematics 
have devoted a great deal of attention to the problems of 
consistency and completeness. The problem of consistency is 
Important since If the foundat Ions are I neons I stent then any 
formula whatsoever may be deduced, thus trivializing the 
foundations. Semantics for foundations of mathematics are 
defined model theoretically in terms of the notion of 
satisfiability. The problem of completeness. Is that for a 
foundation of mathematics to be Intuitively satisfactory all 
the true formulas should be proveable since a foundation for 
mathematics alms to be a theory of mathematical truth. 

Similar fundamental questions must be faced by a 
foundation for problem solving. However there are some 
important differences since a foundation for problem solving 
aims more to be a theory of actions and purposes than a 
theory of mathematical truth. A foundation for problem 
solving must specify a goal -or iented formalism In which 
problems can be stated. Furthermore there must be a 
formalism for specifying the allowable methods of solution. 
As part of the definition of the formalisms, the following 
elements must be defined: the data structure, the control 
structure, and the primitive procedures. Being a theory of 
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actions, a foundation for problem solving must confront the 
problem of change: How can account be taken of the changing 
situation in the world? In order for there to be problem 
solving, there must be an active agent called a problem 
solver. A foundation for problem solving must consider how 
much knowledge and what kind of knowledge problem solvers 
can have about themselves. In contrast to the foundation of 
mathematics, the semantics for a foundation for problem 
solving should be defined In terms of properties of 
procedures, We would like to see mathematical 

Investigations on the adequacy of the foundations for 
problem solving provided by PLANNER, In chapter P of the 
dissertation, we have begun of one kind of such an 
Investigation. 

To be more specific, a foundation for problem 
solving must concern itself with the following complex of 
topics: 



PROCEDURAL EMBEDDING: How can "real world" knowledge be 
effectively embedded In procedures. What are good ways 
to express problem solution methods and how can plans 
for the solution of problems be formulated? 

GENERALIZED COMPILATION: What are good methods for 
transforming high level goal -oriented language into 
efficient algorl thms. 

VERIFICATION: How can It be verified that a procedure 
does what is intended. 

PROCEDURAL AbSTRACTION; What are good methods for 
abstracting general procedures from special cases. 
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One formulation of a foundation for problem solving 
requires that there should be two distinct formalisms: 

la A METHODS formalism which specifies the allowable 
methods of solution 

2: A PROBLEM SPECIFICATION formalism in which to pose 
problems. 

The problem solver is expected to figure out how to combine 
Its available methods In order to produce a solution which 
satisfies the problem specification. One of the alms of the 
above formulation of problem solving Is to clearly separate 
the methods of solution from the problems posed 50 that It 
Is impossible to "cheat" and give the problem solver the 
methods for solving the problem along with the statement of 
the problem. We propose to bridge the chasm between the 
methods formalism and the problem formalism. Consider more 
carefully the two extremes In the specification of 
processing: 

A: Explicit processing (e.g. methods) Is the ability to 
specify and control actions down to the finest details, 

B: Implicit processing (e.g. problems) is the ability 
to specify the end result desired and not to say much 
about how It should be achieved. 

PLANNER attempts to provide a formalism In which a problem 

solver can bridge the continuum between explicit and 

Implicit processing. We aim for a maximum of flexibility so 

that whatever knowledge Is available can be Incorporated, 

even If it Is fragmentary and heuristic* 
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PLANNER is a high level/ goal-oriented formalism In 
which one can specify to a large degree what one wants done 
rather than how to do it. Many of the primitives In PLANNER 
are concerned with manipulating a data base In a pattern 
directed fashion. Most of the primitives have been 
developed as extensions to the formalism when we have found 
problems that could not otherwise be solved In a natural 
way. Of course the trick is to Incorporate the new 
primitive as a genuine extension of wide applicability. 
Others have suggested themselves as adjuncts in order to 
obtain useful closure properties in the formalism. VJe would 
be grateful to any reader who could suggest problems that 
would seem to require further extensions or modifications to 

the formal ism. 

There are many ways in which one can approach a 
description of PLANNER. In this section we will describe 
PLANNER from an Information Processing Viewpoint. To do 
this we will describe the data structure and the control 
structure of the formalism. 

DATA STRUCTURE; 

GRAPH MEMORY forms the basis for PLANNER'S data 
space which consists of directed graphs with labeled 
arcs. The operation of PUTTING and GETTING the 
components of data objects have been generalized to 
apply to any data type whatsoever. For example to 
PUT the value CANONICAL on the expression (♦ X Y (* 
X Z}) under the Indicator SIMPLIFIED Is one way to 
record that (+ X Y (* X Z>) has been canonlcally 
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simplified. Then the degree to which an expression 
Is simplified can be determined by RETTING the value 
under the Indicator SIMPLIFIED of the expression. 
The operations of PUT and GET can be Implemented 
efficiently using hush coding* Lists and vectors 
have been Introduced to gain nore efficiency for 
common special purpose structures. The p,raph memory 
is useful to PLANNER in many ways. Monitoring rives 
PLANNER the capability of trapping all read, write, 
and execute references to a particular data object. 
The monitor (which Is found under the indicator 
MONITOR) of the data object can then take any action 
that It sees fit In order to handle the situation* 
The graph memory can be used to retrieve the value 
of an identifier i of a process p by GETTING the ( 
component of p. Code can be consented by sinply 
FUTTING the actual comment under the Indicator 
CUMMENT. 

DATA UASE: What is most distinctive about the way 
In which PLANNER uses data Is that It has a data 
base in which data can be Inserted and removed. For 
example inserting (AT Bl P2) Into the data base 
might signify that block Bl is at the place P2, A 
coordinate of an expression Is defined to be ?n atom 
In some position. An expression Is determined by 
its coordinates. Assertions are stored in buckets 
by their coordinates using the graph memory In order 
to provide efficient retrieval. In addition a total 
ordering is imposed on the assertions so that the 
buckets can be sorted. Imperatives as well as 
declaratives can be stored in the data base. We 
might assert that whenever an expression of the form 
(At objectl placel) is removed from the data base/ 
then any expression In the data base of the form (ON 
objectl obJect2) should also be removed from the 
data base. The data base can be tree structured so 
that it Is possible to simultaneously have several 
local data bases which are Incompatible. 
Furthermore assertions In the data base can have 
varying scopes so that some will last the duration 
of a process while others are temporary to a 
subroutine. 



CONTROL STRUCTURE: PLANNER uses a pattern directed 
mul 1 1 process backtrack control structure to tie the 
operation of Its primitives together. 
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BACKTRACKING: PLANNER processes have the capability 
of backtracking to previous states, A process can 
backtrack into a procedure activation {i.e. a 
specific Instance of an invocation of a procedure) 
which has already returned with a result. Using the 
theory of comparative schema to logy, we have proved 
In chapter S of the dissertation that the use of 
backtrack control enables us to achieve effects that 
a language (such as LISP) which Is limited to 
recursive control cannot achl eve. Backtracking cuts 
across the subroutine structure of PLANNER. 
Backtrack control allows the consequences of 
elaborate tentative hypotheses to be explored 
without losing the capability of rejecting the 
hypotheses and all of their consequences. A choice 
can be made on the basis of the available knowledge 
and If It doesn't work, a better choice can he made 
using the new information discovered while 
investigating the first choice. Also backtrack 
control makes PLANNER procedures easier to debug 
since they can be run backwards as well as forwards 
enabling a problem solver to "zero In" on bugs. 



MULTIPROCESSING gives PLANNER the capability of 
having more than one locus of control In problem 
solving. ay using multiple processes, arbitrary 
patterns of search through a conceptual problem 
space can be carried out. Processes can have the 
power to create, read, write, Interrupt, resume, 
single step, and fork other processes. 

PATTERN DIRECTION combines aspects of control and data 

structure. The fundamental principle of pattern 

directed computation Is that a procedure should be a 

pattern of what the procedure Is Intended to accomplish. 

In other words a procedure should not only do the right 

thing but it should appear to do the right thing as 

well I PLANNER uses pattern direction for the following 
operations: 

CONSTRUCTION of structured data objects Is 
accomplished by templates. We can construct a list 
whose first element Is the value of x and whose 
second element Is the value of y by the procedure (x 
y). If k has the value 5 and y has the value (A B) 
then (x y) will evaluate to {3 (A B)). 

DECOMPOSITION Is accomplished by Hatching the data 
object against a structured pattern. if the pattern 
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(xl x2> Is matched against the data object ((3 ft) A) 
then xl will be given the value (3 b) and x2 will be 
gi ven the value A, 

RETRIEVAL: An assertion Is retrieved from the data 
base by specifying a pattern which the assertion 
must match and thereby bind the Identifiers In the 
pattern. For example we can determine if there Is 
anything In the data base of the form (ON x A) . If 
(ON B A) is the only I tern In the data base, then x 
is bound to B. If there is more than one Item In the 
data base which matches a retrieval pattern, then an 
arbitrary choice Is made. The fact that a choice 
was made Is remembered so that If a simple failure 
backtracks to the decision, another choice can be 
made. 

INVOCATION: Procedures can be invoked by patterns 
of what they are supposed to accomplish. For 
example a procedure might be defined which attempts 
to satisfy patterns of the form (ON x y) by causing 
x to be ON y. Such a procedure could be invoked by 
making (ON A B) a goal. The procedure might or 
might not succeed In achieving Its goal depending on 
Che environment In which It was called. Since many 
theorems might match a goal, a recommendation Is 
allowed as to which of the candidate theorems might 
be useful. The recommendation Is a pattern which a 
candidate theorem must match. 

One basic Idea behind PLANNER Is to exploit the 

duality that we find between certain Imperative and 

declarative sentences. Consider the statement ( Impl les A 

fl). The statement is a perfectly good declarative. In 

addition, it can also have certain imperative uses for 

PLANNER. It can say that we might set up a procedure which 

will note whether A Is ever asserted and If so to consider 

the wisdom of asserting U In turn. (Note: It is not always 

wise! Suppose we assert (Integer 0) and (implies (Integer 

n) (Integer (+ n 1))|. Furthermore it permits us to set up 
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a procedure that will watch to see If it is ever our goal to 
try to deduce B and If so whether A should he made a 
subgoal * Exactly the same observations can be made about 
the contraposl tlve of the statement (Implies A B) which Is 
(Implies (not B) (not A)). Statements with universal 
quantifiers, conjunctions, disjunctions, etc. can also have 
both declarative and Imperative uses. PLANNER theorems ^vq 
used as Imperatives when executed and as declaratives when 
used as data. The imperative analogues have the advantage 
that they can more easily express any procedural knowledge 
that we might have such as "Don't use this theorem twice". 

Our work on PLANNER has been an Investigation In 
PROCEDURAL EPISTEMOLUGY, the study of how knowledge can be 
embedded in procedures. The TMESIS OF PROCEDURAL EMBEDDING 
is that intellectual structures should be analyzed through 
their PROCEDURAL ANALOGUES. We will try to show what we 
mean through examples: 



DESCRIPTIONS are procedures which recognize how well 
some candidate fits the description, 

PATTERNS are descriptions which match configurations 
of data. For example <elther U <atomlc>> Is a 
procedure which will recognize something which Is 
either k or is atomic* 

DATA TYPES are patterns used In declarations of the 
allowable range and domain of procedures and 
Identifiers. More generally, data types have 
analogues in the form of procedures which create, 
destroy, recognize, and transform data. 
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GRAMMARS: The PROGRAMMAR language of Terry Uinograd 
represents an important step step towards one kind 
of procedural analogue for natural language grammar. 

SCHEMATIC DRAWINGS have as their procedural analogue 
methods for recognizing v/hen particular figures fit 
wi thl n the schemata. 

PROOFS correspond to plans for recognizing and 
expanding valid chains of deductions. Indeed many 
proofs can fruitfully be considered to define 
procedures whl ch are proved to have certain 
properties. 

MODELS are col lections of procedures for simulating 
the behavior of the system being modeled. MODELS of 
PROGRAMS are procedures for defining properties of 
procedures and attempting to verify the properties 
so defined. Models of programs can be defined by 
procedures which state the relations that must hold 
as control passes through the program. 

PLANS are general, goal oriented procedures for 
attempting to carry out some task. 

THEOREMS of the QUANT IF ICATIONAL CALCULUS have as 
their analogues procedures for carrying out the 
deductions which are justified by the theorems. For 
example, consider a theorem of the form (IMPLIES x 
y). One procedural analogue of the theorem Is to 
consider whether x should be made a subgoal In order 
to try to prove something of the form y. 

DRAWINGS: The procedural analogue of a drawing Is a 
procedure for making the drawing. Rather 
soph! stlcated display processors have been 
constructed for making drawings on cathode ray 
tubes. 

RECOMMENDATIONS: PLANNER has primitives which allow 
recommendat Ions as to how disparate sections of goal 
oriented language should be linked together In order 
to accomplish some particular task. 



GOAL TREES are represented by a snapshot of the 
Instantaneous configuration of problem solving 
processes. 
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One corollary of the thesis of procedural embedding 
Is that learning entails the learning of the procedures in 
which the knowledge to be learned Is embedded. Another 
aspect of the thesis of procedural embedding Is that the 
process of going from general goal oriented language which 
is capable of accomplishing some task to a special purpose,, 
efficient, algorithm especially designed for the task should 
Itself be mechanized. By expressing the properties of the 
special purpose algorithm in terms of their procedural 
analogues, we can use the analogues to establish that the 
special purpose routine does in fact do what it is intended. 

From the above observations, we have constructed a 
formalism that permits both the imperative and declarative 
aspects of statements to be easily manipulated. PLANNER 
uses a pattern-directed Information retrieval system. The 
data base is interrogated by specifying a pattern of what is 
to be retrieved. Instead of having to explicitly name 
procedures which are to be called, they can be Invoked 
implicitly by a pattern (this important concept Is called 
PATTERN-DIRECTEO INVOCATION). When a statement Is asserted, 
recommendations determine what conclusions will be drawn 
from the assertion. Procedures can make recommendations as 
to which theorems should be used In trying to draw 
conclusions from an assertion, and they can recommend the 
order in which the theorems should be applied. Goals can be 
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created and automat ical 1 y dismissed when they are satisfied. 
Objects can be found from schematic or partial descriptions. 
Provision is made for the fact that statements that were 
once true In a model may no longer be true at some later 
time and that consequences must be drawn from the fact that 
the state of the model has changed. Assertions and goals 
created within a procedure can be dynamically protected 
against interference from other procedures. Unlike some 
other formalisms such as GPS, PLANNER has no explicit goal 
tree. Instead the compucatlon itself can be thought to be 
invest I gat 1 ng some conceptual problem space, Pr 1ml 1 1 ves for 
a multiprocess backtrack control structure give flexibility 
to the ways in which the conceptual problem space can be 
investigated. Procedures written In the formalism are 
extendable In that they can make use of new knowledge 
whether It be primarily declarative or Imperative In nature. 
Hypotheses can be established and later discharged. PLANNER 
has been used to write a block control language In which we 
specify how blocks can be moved around by a robot. We would 
like to write a structure building formalism In which we 
could provide descriptions of structures (such as houses 
and bridges) and let PLANNER figure out how to build them. 
The logical deductive system used by PLANNER is subordinate 
to the hierarchical control structure of the language, 
PLANNER theorems operate within a context consisting of 
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return addresses, goa Is, assertions, bi ndlngs, and local 
chances of state that have been made to the global data 
base* Through the use of this context we can guide the 
computation and avoid doing basically the same work over and 
over again. For example, once we determine that we are 
Working within a group (in the mathemat leal sense) we can 
restrict our attention to theorems for working on groups 
since we have direct control over what theorems will be 
used. PLANNER has a sophisticated deductive system In 
order to give us greater power over the direction of the 
computation. Of course procedures written In PLANNER are 
not intrinsically efficient. A great deal of thought and 
effort must be put Into writing efficient procedures. 
PLANNER does provide some basic mechanisms and primitives In 
which to express problem solving procedures. The control 
structure can still be used when we limit ourselves to using 
resolution as the sole rule of Inference. A uniform proof 
procedure gives very little control over how or when a 
theorem is used. The problem is one of the level of the 
Interpreter that Is used. A digital computer by Itself will 
only Interpret the hardware Instructions of the machine, A 
higher level Interpeter such as LISP will Interpret 
assignments and recursive function calls. At a still higher 
level an Interpreter such as MATCHLESS will interpret 
patterns for constructing and decomposing strucured data. 
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FLANNEK can interpret assertions, find statements, and 
goals. It goes without saying that code can be compiled 
for any of the higher level Interpeters so Chat It actually 
runs under a lower level interpreter. In general higher 
level Interpreters have greater choice In the actions that 
they can take since Instructions are phrased more In terms 
of goals to be achieved rather than In terms of explicit 
elementary actions. The problem that we face Is to raise 
the level of the interpreter while at the same time keeping 
the actions taken by it under control. Due to Its extreme 
hierarchical control and Its ability to make use of new 
Imperative as well as declarative knowledge. It Is feasible 
to carry out very long chains of Inference In PLANNER 
wi thout extreme Inefficiency. 

We are concerned as to how a theorem prover can 
unify structural problem solving methods with domain 
dependent algorithms and data Into a coherent problem 
solving process. By structural methods we mean those that 
are concerned with the formal structure of the argument 
rather than with the semantics of Its domain dependent 
content. 

An example of a structural method Is the 
"consequences of the consequent" heuristic. By the 
CONSEQUENCES OF THE CONSEQUENT heuristic, we mean that a 
problem solver should look at the consequences of the goal 
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that Is being attempted In order to pet an idea of some of 
the statements that could be useful In establishing or 
rejecting the goal . 

We need to discover more powerful structural 
methods* PLANNER Is Intended to prov Ide a computational 
basis for expressing structural methods. One of the nost 
important Ideas In PLANNER Is that It brings some of the 
structural methods of problem solving out Into the open 
where they can be analyzed and generalized. There are a few 
basic patterns of looping and recursion that are In constant 
use among progranmers. Examples are recursion on binary 
trees as In LISP and the FIND statement of PLANNER* The 
primitive FIND will construct a list of the objects with 
certain properties. For example we can find five things 
which are on something which Is green by evaluating 

<FIND 5 x 

<GOAL (ON x y)> 
<G0AL (GREEN y)>> 

which reads "find 5 x's such that x Is ON y and y Is GREEN. 

The patterns of looping and recursion represent 

common structural methods used In programs* They spec) f y 

how commands can be repeated Iteratlvely and recursively. 

One of the main problems In getting computers to write 

programs is how to use these structural patterns with the 

particular domain dependent commands that are aval labia. It 

is difficult to decide which if any of the basic patterns Is 
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appropriate In any given problem. The problem of 
synthesizing programs out of canned loops Is formally 
Identical to the problem of finding proofs using 
mathematical Induction. We have approached the problem of 
constructing procedures out of goal oriented language from 
two directions. The first Is to use canned loops (such as 
the FIND statement) where we assume a-priorl the kind of 
control structure that is needed. The second approach is to 
try to abstract the procedure from protocols of Its action 
In particular cases. 

Another structural method Is PROGRESSIVE REFINEMENT, 
The way problems are solved by progressive refinement Is by 
repeated evaluation. Instead of trying to do a complete 
Investigation of the problem space all at once, repeated 
refinements are made. For example in a game like chess the 
same part of the game tree might be looked at several times. 
Each time certain paths are more deeply explored in the 
light of what other investigations have revealed to be the 
key features of the position. Problems In design seem to be 
particularly suitable for the use of progressive refinement 
since proposed designs are often amenable to successive 
refinement* The way in which progressive refinement 
typically Is done In PLANNER is by repeated evaluation. 
Thus the expression which Is evaluated to solve the problem 
will Itself produce as its value an expression to be 
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evaluated. 

The task of artificial intelligence Is to program 
Inanimate machines to perform tasks that require 
Intelligence. Over the past decade several different 
approaches toward A. I. have developed. Although very pure 
forms of these approaches will seldom be net in practice, we 
find that It Is useful for purposes of discussion to 
consider these conceptual extremes. One approach (called 
results mode by S. Papert) has been to choose some specific 
intellectual task that humans can perform with facility and 
write a program to perform It, Several very fine programs 
have been written following this approach. One of the first 

was the Logic Theorist which attempted to prove theorems In 
the proposi tlonal calculus using the deductive system 
developed In Prlnclpla Mathematlca. The Importance of the 
Logic Theorist Is that It developed a body of techniques 
which when cleaned up and generalized have proved to be 
fundamental to furthering our understanding of A. I. The 
results mode approach offers the potentiality of maximum 
efficiency In solving particular classes of problems* On 
the other hand, there have been a number of programs written 
from the results mode approach which have not advanced our 
understanding although the programs achieved slightly better 
results than had been achieved before. These programs have 
been large, clumsy, brute force pieces of machinery. There 
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!s a clear dancer that the results node approach can 
degenerate Into trying to achieve A. I. via the "hairy 
kludge a month plan' 1 . The problems with "hairy kludges" are 
well known. It Is Impossible to get such programs to 
communicate with each other In a natural and intimate way. 
They are difficult to understand, extend, and modify because 
of the ad hoc way In which they are constructed. 

Another approach to A. I. that has been prominent In 
the last decade Is that of the uniform proof procedure. 
Proponents of the approach write programs which accept 
declarative descr I pt Ions of combinatorial problems and then 
attempt to solve them. In its most pure form the approach 
does not permit the machine to be given any information as 
to how It might solve Its problems. The character table 
approach to A, I, is a modification of the uniform procedure 
approach In which the program is also Riven a finite state 
table of connections between goals and methods. The uniform 
procedure approach offers a great deal of elegance and a 
maximum of a certain kind of generality. Current programs 
that Implement the uniform procedure approach suffer from 
extreme Inefficiency. We believe that the Inefficiency Is 
intrinsic In the approach. 

PLANNER is not necessarily general in the same sense 
that a uniform proof procedure Is general. PLANNER Is 
intended to be a natural computational basis for methods of 
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solving problems In a domain, A complete proof procedure 
for a quantlf icatlonal calculus is general In the sense that 
if one can force the problem Into the form of the input 
language and is prepared to wait eons If necessary then the 
computer Is guaranteed to find a solution If there Is one. 
The approach taken In PLANNER is to subordinate the 
deductive system to an elaborate hierarchical control 
btructure. Although PLANNER itself Is domain independent, 
procedures written in It have differing overlapping degrees 
of domain Independence. Proponents of the uniform procedure 
approach are apt to say that PLANNER "cheats" because 
through the use of Its hierarchical control structure, ft Is 
possible to tell the program how to try to solve Its 
problems. In order to prevent this kind of "cheating", 
they would restrict the Input to consist entirely of 
declaratives. But surely. It Is to the credit of a program 
that It is able to accept new Imperative Information and 
moke use of It. A problem solver needs a high level 
language for expressing problem solving methods even If the 
language Is only used by the problem solver to express Its 
problem solving methods to Itself. PLANNER serves both as 
the language in which problems are posed to the problem 
solver and the language in which methods of solution are 
formulated. PLANNER Is not Intended to be a solution to 
the problem of finding general methods for reducing the 
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combinatorial search Involved to test vihether a Given 
proposition Is valid or not. It is Intended to be a general 
formalism in which knowledge in a domain can be combined and 
integrated. Realistic problem solving programs will need 
vast amounts of knowledge* We consider all methods of 
solving problems to be legitimate. If a program should 
happen to already know the answer to the problem that It Is 
asked to solve, then It Is perfectly reasonable for the 
problem to be solved by table look-up. We should use the 
criterion that the problem solving power of a program should 
Increase much faster than In direct proportion to the number 
of things that it Is told. The important factors In judging 

a program are Its power* elegance, generality, and 
efficiency. 



